Subject: TCP connection management (Andy's 8/12 22:28 note)

From: [email-masked]
Date: Wed, 18 Aug 93 09:42:54 EDT

Andy,
Here are assorted questions and comments on your proposals:

Your model 1 description seems to say 1 TCP connection per DL
connection.  In your next note the same day, you state "We definitely
need 2 connections at the minimum."  Please clarify whether both your
proposals use a connection pair model.

Model 2 combines out-of-band IPMs with multiple circuits on a
transport connection.  Rather than lumping these together, I believe
we should simply discuss (a) is one TC per circuit practical, and if
not, (b) do we really need the out-of-band IPM.  If we can all agree
on these two points, then I think we will be able to move on to "one
versus two versus N TCP connections" issue.

The "one TC (containing 1 or 2 TCP connections) per circuit" question
needs to be decided since it is a fundamentally different solution than
any pacing scheme we have considered.  So far, Shannon, Choon Lee,
Andy, and I have ventured opinions on this - it would be good to hear
from others.  Here are some further thoughts on my part:

- The argument that this will save us from having to invent a pacing
  scheme (and other arguments FOR the proposal) imply that this will be
  the only approach used.  I assume the connect sequences would not
  prevent circuit multiplexing, just that there would be no architected
  DLSw fairness/flow control mechanism for multiplexed circuits.  This
  punishes vendors whose implementation constraints make supporting
  many TCP connections impractical.

- This approach does not remove the requirement for an implementation
  to deal with the circuit fairness issue.  A receiving box still has
  finite resources.  If some memory is being used up by a "bad"
  circuit, it is unavailable to other circuits, whether there is one
  circuit per TC or many, no matter if the space is held by TCP or
  some other component.  All the proposal does is say that only TCP
  mechanisms are available to reflect conditions to one's partner.
  This ties a DLSw implementation more to TCP, making it harder to
  migrate to other platforms.  I agree with the goal of keeping DLSw
  simple so I can see the advantage of standard mechanisms, but I
  think the negatives outweigh that advantage.

- Many parallel TCP connections requires a new TCP port numbering
  scheme, as you suggested.  We would need to devise a strategy for
  interoperation with RFC 1434 boxes.  There may be other reasons to
  consider doing this anyway.

- I do not agree with your statement "If we need to support a LOT of
  DL connections, then we should not really worry about memory".  I
  always worry about memory.  SDLC has a low circuit-to-physical-
  router-port ratio, but in the LAN environment this can be a very
  large number, meaning thousands of circuits in a router.  Not
  everyone has a space-optimized TCP implementation.  Your argument
  that pacing will require more buffer space than the "circuit per TC"
  proposal does not make sense to me.  The buffer space needed for DLSw
  should be independent of whether the buffering is assigned to TCP
  or some other component.

- On connection establishment, my concern was not so much the added
  latency (which is small IF all goes well) but the added complexity.
  Bringing up a circuit can be tricky by itself without added TCP
  connection bring up and take down (e.g., bring up right after take
  down, etc.) considerations.

- There may be more frames flowing on the WAN, both for connection
  establishment and TCP "keep alive" notifications (so you don't have
  to wait minutes to detect a failed TCP connection).  Our customers
  would have problems with this.  I believe we should maintain circuits
  for UI-frame traffic - maybe you are thinking there will only be
  circuits for type 2 traffic?

- If we were to allow muliplexing on some TCs, I still don't understand
  how you are proposing to determine traffic characteristics of a
  circuit.  SKR's 8/12 proposal of dynamically shifting a circuit from
  one TC to another made sense to me as a possible approach, but your
  references to OSI transport classes didn't explain how one knew to pick
  the appropriate class.

Regards,
Peter